In communication networks, overload occurs when a networked service element has insufficient resources (e.g., CPU processing capacity, memory, network bandwidth, input/output, disk resources, etc.) to successfully process all of the requests that it receives. Some networked service elements can experience prolonged overload due to high rates of incoming service requests and/or partial network outage leading to failures. Service elements include—but are not limited to—voice mail server, instant messaging (IM) server, presence server, location server, address book server, subscriber profile server, self-service kiosks, surveillance trigger/input aggregator, mobile-device-originated traffic aggregator or gateway, policy server, protection and security service manager, etc. Focused overload is a special case of a network overload where the overload is focused on a service element. This subset can range from network destination (e.g., a telephone number or an IP address) to a group of switching and network servers.
In the absence of overload control, such overloads can threaten the stability of a communication network, and can cause a severe reduction in successful completion of service requests. Ultimately, service elements can fail to provide service(s) due to lost requests resulting in the unavailability of services to clients. Often, overload problems can compound themselves, which can cause even more sustained load on a service element. Furthermore, during overload, the overall capacity of server(s) can be significantly reduced, since much of their resources are spent rejecting and/or treating loads that they cannot actually process. Under severe overload conditions, the throughput can drop down to a small fraction of the original processing capacity. This is often called congestion collapse. In addition, overload conditions tend to cause service requests to be delayed and/or lost, which can trigger high rates of client abandonment and/or reattempts.
Traditionally, focused overload is controlled in two different ways. One way is by reducing the incoming load by rejecting services. For example, only higher priority sessions or transactions may be allowed and all others may be rejected. Unfortunately, this may cause customer frustration, and ultimately churn, leading to loss of revenue.
Another way focused overload is controlled is by routing the incoming sessions or transaction requests to native standby service elements which are usually owned and operated by the same organization that owns the service elements whose overload needs to be controlled. However, this may call for drastically higher capital and operation expenses because neither the occurrence nor the duration of the overload events can be accurately predicted. Further, certain drawbacks of utilizing native infrastructure element-based implementation of overload control of service elements include:    a) Cost;    b) Time required for testing and integration of overload service elements with network;    c) Static allocation of resources;    d) Less flexibility in repositioning the resources; Tighter coupling of computing and communications resources with pre-designed features and functions including services (that are traditionally offered by the service element that is being protected from overload); and    e) Reduced opportunity for system upgrade and innovation
Service providers in a dynamic and continuously-evolving networking and service development environment need:    a) Protection of investment, i.e., investment in the resources that can be rapidly repositioned or repurposed for different revenue generating applications and services; and/or    b) Agility and flexibility, i.e., deploying emerging features and functions utilizing the computing and communications resources that already exist in the network.
Accordingly, there is a need for a system that enables network operators and service providers to allocate their budget for computing, communications, and control infrastructure development based on expected design limits. Consequently, there would be no need to create and install silos of computing and networking gears for controlling focused overload of service elements.